Retired NASA engineer
Hal Greenlee
sheds some light
on the Amiga's involvement
in the US space program

The date: 17 February 1996; the time: 20:39 GMT.

At Cape Canaveral's Complex 17, the countdown for Delta 232 has entered the final four minute count. Aboard is a spacecraft called NEAR, destined for an encounter with the asteroid Eros. Blockhouse engineers are conducting the last preparations as they are called out by the test conductor. At T-0, a large liquid-fuelled engine and six of the nine solid boosters will ignite, generating over 640,000 pounds of force, and lifting the 125 foot vehicle rapidly upward with an incredible light and sound show.

At Hangar AE, about five miles away, a group of engineers fill a large telemetry lab, monitoring more than a thousand measurements from the bird. They include people from NASA, McDonnell Douglas (the launch vehicle manufacturer), Johns Hopkins Universi ty (the spacecraft builder), and every contractor who has components on the Delta. No direct control over the launch is exerted from AE, but these people Ð more than you could fit into the blockhouse Ð are essential to the operation.

Eighty-six, 8-channel strip chart recorders, more than 50 video monitor/callbox stations, and three high-speed printers present the data within the building. The data is also being sent to Aerospace Corporation in California by 56Kb data lines, and loc ally to Complex 17 and the E&O building, where other company engineers can follow every step. Also in Hangar AE, a number of management personnel sit in the Mission Director's Center where they can communicate with the pad and every worldwide site inv olved in the operation. During the launch, displays will show them the occurrence and time of each important event, and all of this data is processed by a group of powerful computers in the back of AE Ð a set of Amigas.

Wait a minute! Amigas? Not IBM or Honeywell mainframes? Hey, this is a $112 million spacecraft, give or take, not counting the cost of the booster and launch. Are these engineers really looking at data processed entirely on $2500 computers? They are in deed.

Since 1987, the Amiga has played a little-known role in over 100 launch operations of the two principle United States unmanned launch vehicles Ð the Delta and the Atlas-Centaur. These programs have not enjoyed as much publicity as the manned progra ms, but over the past 36 years they have lofted more than 300 scientific, communications, weather and navigational satellites and probes, and with a high degree of reliability. To see how and why Amigas entered the picture, a little history is required.

The Delta, first launched in 1960, consisted of a Thor booster and a second and third stage based on technology developed for the Vanguard launch vehicle. It was built by Douglas Aircraft and others, and program management was done for NASA by Goddard Space Flight Center. The Center placed a team at Cape Canaveral mostly made up of ex-Vanguard people. Called the Field Projects Branch, we were housed in the same Hangar S that was used to prepare the Mercury missions. We built and operated a small teleme try station that NASA engineers used to monitor Delta pad tests and launches.

The primary function of telemetry is to tell us about things that are going right or wrong with a very expensive craft that may be thousands of miles away. Without accurate analysis of errant flight events, engineers would be powerless to fix the probl em for the next flight. Project managers who decided to save money by cutting back on telemetry coverage have often regretted it.

The general rule is to try to have coverage (radio reception) during all critical events, which include powered flight phases, stage separations, and reorientations. This is why the Air Force and NASA have long maintained a string of telemetry and rada r stations along the typical flight path to the southeast of the Cape, and ships and planes that could fill in any critical gaps. But many of the potential flight problems can be uncovered in the month or so during which a launch vehicle is erected on the pad and is run through many tests and simulations. NASA took the approach that having its own engineers both at the pad watching operations, and at an independent telemetry facility scrutinising test data, gave an extra measure of insurance, well worth t he cost.

By 1961, the Branch moved next door to Hangar AE where there was a lot more room, badly needed for a larger telemetry station and antenna towers. The early Delta had about 130 measurement channels, and these were displayed mainly on strip chart recorde rs, which engineers stood over in rapt attention during major tests. Computers were not essential at that time for telemetry display, but then we got more work. NASA Headquarters decided to move management of the new Atlas-Centaur launch vehicle from Mars hall Space Flight Center and its field organisation, overburdened with work on the Saturn manned boosters.

Lewis Research Center became the new managers; we, by this time known as Goddard Launch Operations, were handed launch responsibilities. This vehicle had a standard Atlas first stage, but its Centaur second stage had something new: the first liquid hyd rogen-liquid oxygen engine system, which offered a big gain in performance. Much that was learned in developing and flying the Centaur stage was valuable to the Saturn and Shuttle programs. The Centaur's complex nature required about 500 telemetered measu rement channels.

We decided in the late 1960s to buy a Raytheon 703 minicomputer for Hangar AE to help process all these measurements. This machine had 64Kb of core memory, and no disk drive. It was programmed in assembly language, and data was entered on paper tape or punch cards. But the volume and complexity of the Centaur telemetry, with its PCM (pules code modulation) links and hundreds of ÔdiscreteÕ (on/off) channels and, likewise, upgrades to the Delta telemetry, made it necessary to replace the 703 in the mid-1970s with a pair of Raytheon RDS-500s. They had a total of 256Kb RAM, and sported 10Mb disk drives the size of small washing machines. For a single vehicle, one machine had to process data, while the other generated displays. Even so, not all the data could be handled, including Centaur's guidance data. With two pads for each of the two birds, and multiple simultaneous operations getting to be more frequent, the minis required constant switching and hard drive cartridge changing.

In the Õ80s, the Space Shuttle entered service. NASA planned to taper off and end the Delta program. Future plans called for satellite launches to be done, often in pairs, by the Shuttle. And there was a program called Shuttle-Centaur for launch ing large deep-space probes Ð more risky and complex by nature than anything before. It required taking a special Centaur (cryogenic-fuelled, remember) stage into orbit in the Shuttle's hold for on-orbit release and launch.

A Honeywell DPS-8 mainframe computer costing millions of dollars was bought for a new facility to support Shuttle-Centaur and other Centaur operations. AE was too small for this monster, which filled a large room and had about 30 people devoted to its care and feeding. AE had other problems. By 1984, Raytheon was telling customers that the 500 was obsolete, and support for its assembly language (in which all our real-time software was written), and hardware was soon going to end. Unmanned Launch Operat ions, as we were called after our transfer into Kennedy Space Center, had an uncertain future, and an overloaded, obsolete computer system.

1986 brought the tragedy of the Challenger accident. In its aftermath, many decisions were made that affected the unmanned programs. One was that Shuttle use for commercial launches would be minimised; only launches that required manned presence, had n ational priority or required the Shuttle's lift capability would continue. The Air Force also decided that it would not put any more of its spacecraft on the Shuttle unless necessary, because it did not have enough control to prevent delays to military pr oject schedules. After extensive reviews, NASA also decided to scrap the Shuttle-Centaur project as too dangerous; only non-cryogenic (but lower performance) booster stages would be launched from the Shuttle. So the Delta program would continue to be need ed after all. NASA's participation in the new facility was cancelled, and the Honeywell DPS-8 became a computer in search of a home. It was too large and expensive for AE's purposes Ð we needed smaller, reasonably priced computers. But what would we c hoose?

Some of us at AE had experience with Motorola 6809 and 68000 processors. Dave Brown, the programmer then in charge of the Raytheons, had done some projects using the VME bus/68000 series cards. I did several 6809-based projects in assembly language. We liked the straightforward programming model the 68000 presented, with its linear memory addressing as opposed to the convoluted segmentation scheme used by the Intel processor. But in 1985, there were no complete, low-cost computers based on the 68000; t here were only minicomputers costing $30-50 thousand (1996) that were too expensive for our needs.

Are you surprised that cost would be an important factor in doing a NASA job? Fact is, there has always been more pressure on the unmanned space projects to keep costs low. Supplying all parties concerned with the best telemetry and communications poss ible is valuable insurance against unnoticed problems and consequent failures, and that has always been Hangar AE's major service. But like all insurance, its benefits are measured by the customers (the management of companies involved in a launch project ) against the cost (of operating AE, partly paid by them). Skip Mackey, who very ably ran the Hangar AE facilities for 36 years, was vigilant in ensuring that we operated efficiently and cheaply, and with the flexibility to provide new services, often nee ded at the last minute. Replacing the Raytheons was going to have to be done at low cost, or Skip would not go for it.

Dave Brown, myself and others were reading about the new 68000-based Atari ST during 19885, but decided it was too limited for AE's purposes. Then we heard about the Amiga 1000. A nearby store started to carry them in late '85, so I went by to get a de monstration. I had the same reaction that many of us may remember: amazement! Here was a relatively low-cost computer that did things no other small computer could! After a while, I brought one home, and then took it AE for show and tell. Dave Brown was a lso impressed, and got one for himself. The Amiga fix was in.

Cost was not a problem in replacing our minis with Amigas, but some other things were. A well-made peripherals box was needed that would accept accessory cards and hard drives. It would have to include a hard disk controller card, and additional slots for DMA data input and output cards of our own design. We looked at designs by MicroForge (huge and slow), CSA and ASDG (just card frames) without much enthusiasm.

Then a Texas company called Byte-by-Byte announced its PAL 1000 box. It offered everything we wanted: five Zorro I slots, three hard drive slots, an extra megabyte of RAM and a clock. It was well buffered and powered, and sat conveniently on top of the 1000. Most importantly, it came with a disk controller, developed jointly with Commodore Ð this was the forerunner of the CBM 2090A. At the time, Commodore hadn't gotten the SCSI part of the card to work, so PAL boxes came with 42Mb ST-506 drives. We bought the first PAL box produced, and ten more later. This item made it possible for us to use the Amiga. It gave us the same and more capability that the 2000 would have later, but by the time the 2000 came out, we would have gone another way. Note: th e PAL box design was done by Brad Carvey of Video Toaster design fame, and comedian Dana Carvey's brother.

Another problem was that we needed floating-point processing, and a faster CPU than the 68000, even with the load split between the three operational Amigas. We found a 68020 card, the Ronin Hurricane, that had a doubled clock speed, a true floating po int co-processor, and space for 4Mb of 32-bit RAM. This, with our custom cards, completed the setup for our first operational systems.

While the RDS-703 and RDS-500 software had all been done in assembly language, the decision was made that all Amiga coding would be in C language. This allowed maximum ease for the constant upgrades and additions that would be needed, and good portabil ity, in case another machine change became necessary. Although not as fast as machine language, C certainly was better than high level languages. Care was taken to ensure that multitasking was preserved and that the same software would run on all Amigas f or all missions. We started with the Manx Aztec compiler, switching to SAS/C when it became necessary.

Dave Brown soon added other programmers, and presently there are four: Dave, Gary Jones, Lois Clutter, and Eric Anderson. This is a non-stop job for these folks, done between and during operations. The special hardware designs, such as the I/O cards, a re mostly done by Charlie Michael. We have our own PC lab to build prototype cards. Getting us developer status, I cultivated friends in Commodore and third-party companies, chasing answers to problems, and evaluating new products. John Vining and I both did purchasing (since I retired, he's stuck with it all!).

We named our triple Amiga system ÔCARDSÕ Ð Computer-Aided Recording and Display System. It has the power to handle not only all the measurements on one Delta or Centaur, but to deal with two or more tests on different pads at the same time. The programmers can shift the assignments of data handling between Amigas in real time without shutdowns. Usually, there is one Amiga on each vehicle during its prelaunch tests, but the system is completely flexible. On a Delta launch day, the telem etry from that vehicle will probably be divided between the three primary Amigas, with three more as backups. But if Centaur wants to run tests also, it can simply be added to one of the machines.

The basic system consists of the following elements: data is received by RF links directly from the missile, and also from landlines from the blockhouse; other telemetry sites may also be sources, always the case on launch day. The PCM (Pulse Code Modu lation, now mostly used in preference to the older pulse amplitude, pulse duration and FM/FM) data is processed by a decommutator on each link. The digital data from all such sources is placed together on the telemetry lab's link multiplexer, a bus that r uns at 7 megabits/sec. Each channel (measurement) value includes a tag that identifies it and its source. At the Amigas, the input cards contain dual-ported RAM where all the link mux data is stored, and the system software can then access the data which is needed, placing it in a large table in memory. This table, identical in all of the Amigas, is updated with every sample of every measurement, as each new PCM frame arrives at the input card.

The computer does various operations on the data in the table, including scaling the data from 0 to 100 per cent, converting to engineering units, or any special function. Translating a measurement to engineering units for video display or printout in numerical form is not usually a linear conversion. It involves fitting the value to a curve, and six coefficients are supplied by the vehicle manufacturer for each measurement channel. The curve and coefficients would vary with each transducer on board, f or example, one that measures oxidiser tank pressure on the first stage. If that transducer fails and is replaced, we have to get the new coefficients, and again, they can be entered while the main program is running. A fifth-degree polynomial calculation by the Amiga, using those coefficients, provides an engineering value, which would probably be in pounds pressure in this case.

Another operation the computers do is to decommutate certain data that is included in a PCM link, but running asychronously at a frame rate different from the link's main frame rate. The new Delta II AUV (Avionics Upgrade Vehicle) has its guidance data embedded this way.

The real-time processing is interrupt-driven, but the pre-emptiv multitasking is what makes it possible to do so many things while the program is running, such as changing sources, displays, channel assignments, scales, coefficients, and adding or remo ving additional tasks.

The output of all this activity? Each of the three Amigas feeds a video generator bank which can output 32 out of about 1000 possible video pages (for ÔdiscretesÕ, another 2000 possible pages). These pages use a large font, preferred by th e users, which allows 16 lines per screen. Most of the 96 video outputs are fed to monitor/callbox sets installed in consoles throughout the building. Next to each monitor, the callbox has a numerical keypad and LED display. CARDS also drives large sets o f DACs (Digital-to-Analog Converters), which in turn can drive about 700 strip chart channels. Engineers need these as a continuous record of a launch or test so they can see not only measurement levels, but when various events took place.

For instance, if you were an engineer concerned with first stage tanking, you would have requested your tank pressure, temperature and level measurement pages beforehand. You could switch among those and any other pages of measurements from the vehicle with the keypad, the LEDs showing you which page is selected. The Amiga CARDS program allows you to key in additional measurements to one of your pages, or make a new page. You could also enter a request for a line printer printout of your data, step to the printer, and it would be waiting. And you would have your more important measurements being recorded continuously on nearby strip chart recorders, so you could check the recent history of your measurements.

After every major test, these charts are stretched out on long racks for scrutiny. In case of a launch failure or performance off the mark, strip charts are invaluable for analysing the data. In addition, all telemetry is recorded on magnetic tapes dur ing tests, and can be played back into the entire system later.

Separate Amigas are used in the telemetry lab for other purposes. Some 2000s are used to control the DACs referred to above; others are used to program the decommutators that process the PCM data. Another Amiga runs the timing system display in the Mis sion Director Center. This rather elaborate system was originally run by a PC, with some very expensive C code done under contract, but the source was recompiled for the Amiga by Eric Anderson in a few week's work, and since then the timing system has bee n tailored to do the job better.

A smaller, but almost identical system was also installed at the Western Test Range (Vandenberg AFB, California), to support NASA Delta and Scout launches, which have been much less frequent. Some of our customers wanted to have a system located at the ir facility that would function like CARDS, driven by data from the Cape or WTR. Dave Brown developed a system where a single-Amiga CARDS could be remotely placed, and driven by data typically transmitted across 56Kb circuits. The remotes operate on a two -second delay, but receive all measurements correctly time-tagged, and the engineers at the remote site have the same ability to display, customise and print out all their data pages.

All software maintenance can be done at the transmitting end, including swapping the real-time executing software, rebooting, and verifying proper function. The remotes run the same software as the primary Amigas, with conditionals set to optimise them for their more limited job. Remotes are in operation at Lewis Research Center, Aerospace Corporation, and several facilities on the Canaveral Air Force Station and Kennedy Space Center.

Not limiting ourselves to launch vehicle support, Hangar AE has been able to provide data for spacecraft checkout and other special projects on a number of occasions. These include the GOES spacecraft, the GPS navigational series satellites, the ACTS s pacecraft, the TOS third stage, and the Pegasus booster series, which are air-dropped from a modified L-1011 aircraft. Another extra has been supporting CAS (Customer Ancilliary Service) slow-speed data from the mid-deck experiments carried by the Shuttle ; this data runs for long periods during launch preparation.

Time travelling

Going back for more history, improvements to the 1000 systems came steadily. Although Byte-by-Byte stopped making the PAL box, I found an engineer who had worked on the disk controller. He had finally got the SCSI section working, s o we got him to sell us kits to upgrade our cards. We were then free to use more, larger, and faster storage drives. Before long, I wanted a replacement for these cards, which wouldn't run some devices. I discovered that I could cut a GVP Series 1 SCSI ca rd in half and it would fit inside the PAL box, so we did that. Then we could use Bernoulli 44Mb drives which helped us preserve and transport software easily. Also, some users brought us data on 9-track tapes; our tape deck had an ISA bus SCSI controller , so we ran it from a bridgeboard inside a 2000.

By 1991, we were moving along with plans to replace the 1000/PAL Box systems with Amiga 2500s. This required Charlie to re-do our DMA input and output cards which was not so easy because the original square card was already crowded, and the Zorro II ca rd had less real estate available. Since the A2630 68030-25 accelerator cards would only take 4Mb of RAM, we soon added DKB's 2632 cards to them, allowing up to 112Mb worth of SIMMs. Then I found a new product at a show, called (no kidding!) the CSA Rocke t Launcher Ð it was a CPU/FPU speed doubler for the A2630. It gave a big performance boost, so we soon had one installed in each of them. We then had a system running at 3.5 times the speed of the original 1000 systems, and with no practical RAM limit ations. The original systems are still being used at remote sites where they can do everything needed.

Conscious that PCM data rates would be increasing, we wanted to use the Amiga 4000 as our third-generation machine. We thought we would be able to buy 4000Ts in early 1994, but instead, Commodore went bust. As I was retiring in May '94, the new plan wa s to buy 4000 desktop machines, put the motherboards in Micronik tower cases, and put 40MHz 040 Warp Engines in them. NASA was able to get about half the 4000s needed, but had been waiting for five units from a local dealer for many months. That November, I went to the Computer 94 show in Cologne, hoping for a miracle. A German friend made some calls for me while I was there, and we found a dozen 4000s in a store 150Km. away. Problem solved.

The pictures show these tower-cased machines. They may not look like Amigas but they are working very well, thank you. Charlie Michael recently designed new dual-ported RAM I/O cards that side-stepped delays due to the DMA process in the original desig n. Now the system hard drives are gigabyte capacity, and the Bernoulli's,150Mb size. DAT tape is used for backups, and CD-ROM read/write drives provide more permanent storage.

Running out of time?

The present AE Amigas have enough power for a few more years, but telemetry systems speeds are being increased steadily. The Centaur presently uses a 256Kb PCM rate. The first Delta PCM systems ran at 13.89Kb but the new AUV systems run at 367 and 500Kb. Titan, which is occasionally used by NASA, is up to 800Kb. The Cassini mission to Saturn, with support beginning in late 1997, will use a Titan booster, and this project may push the Amigas pretty hard.

The computer team is looking at the 68060 cards that are available to replace the Warp Engines, but the potential of those cards will be somewhat limited until an optimised 060 compiler is available. Storm C includes 060 switches and looks good in demo form, but the working version is not available with English documents as of the time of writing.

Future storage

The question now on the minds of the Hangar AE crew is the same one most of us have: will VIScorp, or anyone else, such as Phase 5, build an advanced Amiga with a Power PC or other RISC processor? If anyone comes up with the RISC ha rdware and the ported operating system for it, Hangar AE will be ready to try it on for size.

Footnote

I met Hal Greelee for the first time durning the Orlando Amiga Devcon in early 1993. After arranging security clearances in advance, we only had to spend an hour or so with base security before being cleared to the miltary side of the space complex. Hal took me and a group of other Commodore-Amiga engineers on a tour of Hanger AE as we discussed the Amiga's role in their programs and how the Amiga might be improved to better meet their needs. Note that we had to do this on vacation days, as Commodore management had decided that visiting NASA was not sufficiently related to the Amiga developer's conference. At any rate, when we saw mission control, an active countdown was on the board, at something like t-minus 30 hours. The next night, I watched that Delta launch from Cocoa Beach Pier. It lit up the sky brighter than any sunrise I've been witness to. The awe of such a spectacle is amazing of itself, more so for the knowledge that, in however small a part, I was responsible for some of the computers that made it all go. Thanks Hal!